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(57) Abstract 



A data orocessine svstem implements a security protocol based on processing data in packets. The data processing system comprises 
packet processing means (301) for storing filter code (304) and processing data packets according to stored niter code^d pohcy managing 
means (305) for eeneratina filter code and communicating generated filter code to the packet processing means (301). The packet processing 
meaSs (301 b £££ to examine, whether the stored filter code is applicable for processing a certain packet. If the stored ^filter ^codeis 
not applicable for the processing of a packet, the packet is communicated to the policy managing means (305), which generates filter code 
applicable for the processing of the packet and communicates the generated filter code to the packet processing means (301). 
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* imn^mentine IPSEC Policy Management using 
Method and Arrangement for Implementing ir 

Filter Code 

The invention relate, to the field of implementing protocols ft* authenticate and 
encrypt/decrypt packetised digital information. 
The IP security protocol (IPSEC) , 

^™^^ { °'^ZlZ2r^ZZ^ of traffic 
protocol. It provides cryptograph* used to both e „d W 

between two conununicating network nodes^ It can * ™ ^ mode 

rrtio^-^aLtandfteofterendisafirewallorVPNarealso 

possible. 

25 association. 

^ambiguously chosen for each inconung and outgo** packet 

The IPSEC stondard and published implementations present a data structure galled 

Tp^lse, w J is an array or table in memory and eontants rules. The 
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rules in the policy database are consulted for each packet to be processed. Fig. 1 is a 
simplified graphical illustration of a known IPSEC implementation 100, which 
contains a policy database 101 and separates a secure internal network 102 from the 
Internet network 103. For the sake of simplicity, packets flowing only to one 

5 direction (outgoing packets) are considered. The input packets 104 in Fig. 1 contain 
data that a user in the internal network 102 wants to send to another user through 
the Internet and that need to be processed for authentication and encryption. In the 
IPSEC implementation an input packet under consideration 105 is transformed into 
an output packet under consideration 106 by consulting the rules in the policy 

10 database 101. The transformed output packets 107 are then sent into the Internet, 
where they will be properly routed to the correct receiving user. 

On the other hand, mechanisms for filtering IP packets have been available and 
well-known in the literature for a long time. Suitable mechanisms are presented for 
example in J. Mogul, R. Rashid, M. Accetta: "The Packet Filter: An Efficient 

15 Mechanism for User-Level Network Code" In Proc. 1 1th Symposium on Operating 
Systems Principles, pp 39-51, 1987 and Jeffrey Mogul: "Using screend to 
implement IP/TCP security policies", Digital Network Systems Laboratory, NSL 
Network Note NN-16, July 1991. Packet filters also have a set of rules, typically 
combined by a set of implicit or explicit logical operators. The task of a packet filter 

20 is to either accept or reject a packet for further processing. 

The logical rules used in packet filters take the form of simple comparisons on 
individual fields of data packets. Effectively, effecting a such comparison takes the 
form of evaluating a boolean (logical, truth value) expression. Methods for 
evaluating such expressions have been well-known in the mathematical literature for 
25 centuries. The set of machine-readable instructions implementing the evaluations is 
traditionally called the filter code. Fig. 2 illustrates a packet filter 200 with a stored 
filter code 201. Input packets 202 are examined one packet at a time in the packet 
filter 200 and only those packets are passed on as output packets 203 that produce 
correct boolean values when the logical rules of the filter code are applied. 

30 The individual predicates (comparisons) of packet filter expressions typically 
involve operands that access individual fields of the data packet, either in the 
original data packet format or from an expanded format where access to individual 
fields of the packet is easier. Methods for accessing data structure fields in fixed- 
layout and variable-layout data structures and for packing and unpacking data into 

35 structures have been well-known in standard programming languages like fortran, 
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cobol and pascal, and have been commonly used as prograrnming techniques since 
1960's. 

The idea of using boolean expressions to control execution, and their use as tests are 
both parts of the very basis of all modern prograiruning languages, and the 
technique has been a standard method in programming since 1950's or earlier. 

Expressing queries and search specifications as a set of rules or constraints has been 
a standard method in databases, pattern matching, data processing, and artificial 
intelligence There are several journals, books and conference series that deal with 
efficient evaluation of sets of rules against data samples. These standard techniques 
can be applied to numerous kinds of data packets, including packets in data 
communication networks. 

A further well-known technique is the compilation of programming language 
expressions, such as boolean expressions and conditionals, into an mtermediate 
language for faster processing (see, for example, A. Aho, R. Se thi I Ullman^ 
"Compilers - Principles, Techniques, and Tools", Addison-Wesley, 1986). Such 
intermediate code may be e.g. in the form of trees, tuples, or interpreted byte code 
instructions. Such code may be structured in a number of ways, such as i register- 
based, memory-based, or stack-based. Such code may or may not be allowed to 
perform memory allocation, and memory management may be explicit, requiring 
separate allocations and frees, or implicit, where the run-time system automatical^ 
manages memory through the use of garbage collection. The operation of such code 
may be stateless between applications (though carrying some state, such as the 
program counter, between individual intermediate language instructions is always 
necessary) like the operation of the well-known unix program "grep", and other 
similar programs dating back to 1960s or earlier. The code may also carry a state 
between invocations, like the well-known unix program "passwd", most database 
programs and other similar applications dating back to 1960s or earlier. It may even 
be felf-modifying like many Apple H games in the early 1980s and many older 
assembly language programs. It is further possible to compile such mtermediate 
» representation into directly executable machine code for further optimizations. All 
this is well-known in the art and has been taught on university progranumng 
language and compiler courses for decades. Newer well-known research has also 
presented methods for incremental compilation of programs, and compiling portions 
of programs when they are first needed. 
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Real-time filtering of large volumes of data packets has required optimization in the 
methods used to manipulate data. Thus, the standard programming language 
compilation techniques have been applied on the logical expression interpretation of 
the rule sets, resulting in intermediate code that can be evaluated faster than the 
5 original rule sets. A particular implementation of these well-known methods used in 
the BSD 4.3 operating system has been mentioned in popular university operating 
system textbooks and has been available in sample source code that has been 
accessible to students in many universities since at least year 1991. 

Recently, a patent application was filed for the well-known methods of stateless and 
10 stateful filtering; a US patent was consequently granted with the number 5 606 668. 
"Stateless filtering" is essentially the well-known BSD 4.3 packet filter (University 
of California, Berkeley, 1991, published for royalty-free worldwide distribution e.g. 
in the 4.3BSD net2 release), and "stateful filtering" adds to that what Aho, Sethi, 
and Ullman (1987, above) characterize on page 401 with "This property allows the 
15 values of local names to be retained across activations of a procedure. That is, 
when control returns to a procedure, the values of the locals are the same as they 
were when control left the last time." The particular book was probably the most 
popular textbook in university undergraduate compiler courses in late 1980s and 
early 1990s. The idea itself dates decades back. 

20 A known IPSEC implementation must consult the policy database for every packet 
transmitted through the IPSEC implementation. High-speed VPN (Virtual Private 
Network) implementations, for instance, may need to process tens of thousands of 
packets per second. The processing overhead consisting of looking up for policy 
rules from a database for such packets will soon become a bottleneck of 

25 performance. 

The incoming packets to a network device implementing the IPSEC method may be 
classified into regular and non-regular packets. The difference between the two is 
elaborated in more detail below. The invention resides in properly partitioning and 
arranging the tasks of 

30 - generating and mamtaining policy databases, 

- based on the information in the policy databases, compiling filter code to be 
applied on packets, 

- using the compiled filter code for separating non-regular packets from regular 
packets, and potentially processing regular packets, and 
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- creating new pieces of compiled filter code as a potential response to each 
occurrence of a non-regular packet. 

The novel features which are considered as characteristic of the invention are set 
forth in particular in the appended claims. The invention itself, however, both as to 
5 its consLtion and its method of operation, together with additional objects and 
advantages thereof, will be best understood from the following description of 
specific embodiments when read in connection with the accompanying drawings. 

Fig. 1 illustrates a known IPSEC implementation, 
Fig. 2 illustrates a known packet filter, 
10 Fig. 3 illustrates an advantageous embodiment of the invention, 

Fig. 4 illustrates details of information stored according to the invention, 
Fig. 5 is a flowchart representation of the method according to the invention 
and 

Figs. 6. and 6b illustrate some physical implementations of me invention. 

A device or process responsible for implementing the packet *^f«" 
according to the IPSEC method in a network device is generally called an WSEC 
packet processing engine" or an "IPSEC engine" for short. Accordrng to tta 
Lntion, the operations to be performed on incoming and/or outgomg packets may 
to generf be represented by means of a certain filter code, although the 
recrements for a filter code in an IPSEC policy application are much more 
complicated than in the simple packet filtering case referred to above » the 
description of prior art A known packet filter simply sorts mcormng packets mto 
acceple and non-acceptable packets. An IPSEC engine must deal wfttt. 
security policy, the currently active security assoc.at.ons and the transforms 
between Lming and outgoing packets. Additionally, the IPSEC ensure must deal 
with security association creation and expiration and consult external key managers. 

In ,he invention, compiled filter ct.de forms the core of the control logic of an 
IPSEC engine. The filter code controls the processing of incoming and outgomg 
packets, controls the application of transforms applied to data packets, and makes 
30 policy decisions about packets to be dropped or passed without applymg transforms^ 
The filter code communicates with a separate policy manager that makes the actual 
policy decisions and generates new compUed filter code according to need. The 
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need for new compiled filter code potentially arises each time when the IPSEC 
eneine receives a packet that it can not handle according to the existing compiled 
ftecode. The policy manager then implements the policy for the packet causing 
the "trouble" and for similar future packets. 

The compiled filter code effectively acts as a cache of recently made policy 
decisions, and any new decisions are referred to the more general policy manager 
code This makes the difference between regular and non-regular packets evident, 
regular packets bear enough resemblance to some previously handled packet so that 
thf IPSEC engine may apply the compiled filter code. A 

first of its kind to arrive into the IPSEC engine so that the compiled filter code does 
not contain enough information for its handling, whereby the policy manager must 
be consulted and new policy decision(s) must be made, which the, .become s) part 
of the compiled filter code. The invention makes the processing of bulk data very 
efficient yet it allows the full flexibility of a sophisticated, user-mode policy 
manager with arbitrary key management protocols and other features that are 
impossible to implement using known packet filter solutions. The filter code also 
tTan important role in making the system secure and robust; the filter code is m 
most cases able to drop and ignore invalid or unacceptable packets very fast, 
without needing to consult the policy manager. This helps against resource 
exhaustion attacks. The filter code also tightly controls the application of 
transformations, preventing resource attacks by nested encryptions. 

An additional feature to improve robustness is that the filter code is designed in 
such way that it will always terminate, even in the case that an incorrect filter code 
is somehow generated. These features make the filter code particularly suitable for 
execution in an operating system kernel environment for maximal performance. The 
detailed procedure for ensuring termination is discussed more thoroughly below. 

The components of an IPSEC implementation 300 according to a first embodiment 
of the invention are roughly outlined in Figure 3. The IPSEC engine 301 mterfaces 
with a TCP/IP stack and/or network adapters generally represented by block 302 
using a packet interceptor 303 (known as such) which passes IP packets through to 
the IPSEC engine for IPSEC processing. The IPSEC engine 301 performs packet- 
P er-packet processing, such as choosing and applying cryptographic transformations 
on packets as generally described in known IPSEC literature. It also contains the 
filter code mechanism 304 described in this invention. A separate policy manager 
305 maintains the full policy database 306 about acceptable commumcations and 
required authentications, and makes policy decisions about how each packet is to be 
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handled. The key managers block 307 is a further functional entity that 
communicates with the policy manager 305 and performs on its behalf the actual 
key exchanges needed for the IPSEC authentication and/or encryption/decryption 
processes. The key managers block 307 may use in its operation any protocols 
known as such, e.g. the ISAKMP/Oakley protocol, where ISAKMP means Internet 
Security Association Key Management Protocol. 

Different sections of the block diagram in Fig. 3 have different performance 
requirements. The packet interceptor 303 potentially sees every packet in the 
network, including both IP packets and packets according to other protocols. It must 
be able to separate IP packets from the other packets and pass them on to the IPSEC 
engine 301 at the full supported packet rate. The IPSEC engine 301 normally sees 
every IP packet, and it must be able to process these packets also at the full 
supported packet rate. Both the packet interceptor 303 and the IPSEC engine 301 
typically reside in an operating system kernel 308 of the computerized network 
device where the IPSEC implementation 300 takes place to minimize 
communication costs. 

The policy manager 305 and the key manager 307 perform tasks that may take 
longer to complete than operations in the full-rate processing blocks 303 and 301. A 
typical examination of the policy database 306 by the policy manager 305 may 
involve looking at hundreds of individual rules, and may even involve 
communication with external hosts (not shown) to determine the appropriate policy 
in each case. Key exchanges effected by the key managers block 307 often take 
even longer than the policy database examinations, up to several seconds in some 
cases. The policy manager 305 and key managers block 307 also do not have very 
clearly defined resource requirements. It is thus most preferable to implement them 
as user-mode processes in the user-mode process space 309 of the network device. 

Communication between kernel-mode and user-mode processes in a general- 
purpose computer is fairly time-consuming, involving substantial overhead and data 
copying every time a message is passed. Thus it is desirable to reduce the amount of 
such communications. In an embodiment of the invention according to Fig. 3 this 
means reducing the amount of communication between the IPSEC engine 301 and 
the policy manager 305. The filter code mechanism 304 serves this purpose, 
because once a policy decision has been saved into the filter code mechanism in the 
form of compiled filter code, regular packets that can be handled according to that 
filter code cause no further transferring of messages between the IPSEC engine 301 
and the policy manager 305. 
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It is possible and sometimes desirable to implement even the IPSEC engine in user 
mode instead of the operating system kernel. However, due to the different response 
time requirements of the IPSEC engine and the policy manager, it is even then 
desirable to run them in separate threads or processes, which introduces more or 
5 less the same communication overheads as implementing the IPSEC engine in the 
operating system kernel. 

For the system according to the invention to work properly it is important to have a 
well-defined work distribution between the IPSEC engine and the policy manager. 
All packet processing that needs to be done separately for every data packet is 

10 located in the IPSEC engine. When a non-regular packet comes into the IPSEC 
engine, the policy decision about its handling is referred to the policy manager. The 
policy manager will then send information to the IPSEC engine that allows it to 
make similar decisions on behalf of the policy manager concerning the following 
regular packets, until the policy manager sends new information to the IPSEC 

15 engine or some of the information expires. For example, in a typical TCP/IP 
session, the first packet in each direction will be a non-regular packet and gets 
passed to the policy manager, which will examine the packet and determine its 
policy rules. A typical policy will involve processing all packets of a TCP/IP session 
identically, and thus the policy manager may send information to the IPSEC engine 

20 that allows it to recognize future packets belonging to the same TCP/IP session as 
regular packets, and process them accordingly. Both the routine policy decisions for 
the following regular packets and their processing (e.g., encryption) take place in 
the IPSEC engine. The IPSEC engine applies transformations to the packets using 
cryptographic keys and other data it has received from the policy manager, or 

25 possibly from the key managers block through the policy manager. 

There are also other actions besides routine policy decisions that need to be 
performed per packet. For instance, a security association may have a limited 
lifetime defined by the amount of data transmitted using that security association, 
implying that the amount of data already transmitted must be recorded and the 
30 transmission must be dropped or the establishing process of a new security 
association must be initiated if the lifetime expires. Data transmission statistics may 
need to be updated for every packet. All these actions are preferably performed by 
the IPSEC engine. 

There are two types of information the policy manager sends to the IPSEC engine: 
35 security association parameters and compiled filter code. Security association 
parameters are information that are needed to apply an IPSEC transform (e.g., AH 
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or ESP) on a packet. The parameters include such data as encryption keys, 
authentication keys, initialization vectors, reply prevention counters, tunneling 
information, and any other data that may be necessary to parameterize a 
transformation. The compiled filter code, on the other hand, is an executable (or 
5 interpretable) representation of some aspects of the security policy. 

Fig. 4 illustrates in table form the main data items to be stored in a security 
association. Cell 401 includes selectors constraining the security association. Cell 
402 identifies the transformation that should be applied to the packets belonging to 
the security association and cell 403 includes the key material needed in the 
10 transformation. Cell 404 includes replay prevention data for the transmission and 
cell 405 indicates the number of bytes transmitted. Cell 406 includes the expiration 
time and data transfer limit of the security association. 

Security association parameters must be stored in the IPSEC engine separately for 
each security association, as each association typically has different encryption and 

15 authentication keys. Filter code, on the other hand, is typically stored separately for 
each network interface, with separate code for incoming and outgoing packets. The 
reason for this is that storing the code separately for each interface eliminates the 
possibilites for a hostile attacker to make a packet look like it had arrived from a 
different interface than it actually did. Additionally, code paths in the filter code 

20 will be shorter this way, making execution faster. 

Information in the IPSEC engine actually acts as a cache for information stored in 
the policy manager. In other words, it is the policy manager that has authoritative 
information about active security associations. It may, at its discretion, send some of 
that data to the IPSEC engine, and create filter code that processes packets for those 

25 security associations in the filter code, and passes packets for other, less frequently 
used associations to the policy manager, so that the policy manager can then install 
the associations and filter code needed for those packets in the IPSEC engine before 
reprocessing the packet. This allows fixed memory allocation in the IP SEC engine, 
making resource exhaustion attacks against the operating system kernel impossible. 

30 The filter code can also cache the fact that certain types of packets are to be 
rejected, shortcircuiting the processing of unacceptable packets. 

A simple preferable embodiment of a method according to the invention is 
summarized as a flowchart in Fig. 5. Blocks 501 and 502 correspond to the 
operation of the packet interceptor 303 in Fig. 3, i.e. letting only IP packets reach 
35 the IPSEC engine. Blocks 503 to 507 describe operations that take place in the 
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IPSEC engine. In block 503 the IPSEC engine applies the filter code it has 
previously stored. Applying the filter code in block 503 may include performing 
transformations on the packet, but this is not required by the invention. During the 
application of the filter code, the validity of the information stored in the EPSEC 

5 engine is also checked in block 503 for possible security association lifetime 
expirations or other invalidities. If the packet is a regular packet, the IPSEC engine 
knows whether it should drop the packet according to block 504 or accept it 
according to block 505; an accepted packet is output according to block 506. If the 
application of the filter code involved performing a transformation or otherwise 

10 processing the packet, block 506 corresponds to outputting the processed packet. If 
the answer in block 505 was no, the packet is non-regular and it must be transferred 
according to block 507 to the policy manager for examination and policy rule 
determination according to block 508. The resulting new policy decisions are stored 
into the IPSEC engine at block 509 in the form of compiled filter code and the 

15 operation continues from block 503: the packet that caused the visit to blocks 508 
and 509 has now become a regular one because the newly stored compiled filter 
code contains information about how the packet should be treated. 

The policy manager may also process a received non-regular packet by itself as an 
alternative to compiling new filter code and communicating it to the IPSEC engine. 

20 The designer of the policy manager may decide, what kind of non-regular packets 
are worth compiling new filter code and what kind of packets are most 
advantageously processed in the policy manager. Additionally the policy manager 
may process a received non-regular packet by itself and compile new filter code and 
communicate it to the IPSEC engine for the processing of further similar packets. 

25 The last alternative is especially applicable when the received packet is a key 
management packet. 

As explained previously, the filter code is most advantageously stored in the 
operating system kernel. It consists of simple operations that can be executed 
quickly. Examples of filter code operations include comparing a field in the packet 

30 header against a known value and branching based on the result of the comparison, 
optimized multiple-choice selections of values, applying a transformation and 
continuing, dropping a packet, passing the packet through in its current form, and 
passing the packet to the policy manager for further consideration. The filter code 
according to the invention is thus a generalisation of the traditional concept of 

35 evaluating boolean expressions. 
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The filter code in its preferred embodiment has several characteristics which are 
beneficial: 

- It is linear byte code, which means that it can easily be stored and passed around 
in a memory buffer or array. 

5 - All jumps in the byte code are forward, which implies that the filter code will 
always eventually terminate. It is easy to make the interpreter very robust. 

- There are no loops in the filter code. For example, if two transforms are to be 
applied inside each other, separate filter code is generated to process allowed values 
after the first application. This prevents resource exhaustion attacks by multiple 

1 0 layers of encryption using the same security association. 

There are also situations where processing packets in fragmented form is desirable. 
For example, if packets are to be tunneled inside a tunnel-mode AH or ESP 
transformation, it may not be desirable to reassemble the packets before applying 
the transformation, but to instead apply the tunneling transformation separately for 
15 each fragment. 

The filter code in the IPSEC engine can be used for this purpose as well. The filter 
code can be applied to the first fragment of the packet as soon as the fragment has 
been received. A special filter code instruction can be used to abort processing if the 
full packet is needed. This instruction can be used in those code paths of the filter 

20 code that actually require a full packet. Those code paths that can process individual 
fragments (e.g., by applying a tunneling transformation, passing them through 
unmodified, or dropping them) do not include this instruction, and only access the 
part of the packet header that is always guaranteed to fit in the first fragment. 
Information will then be saved outside the filter code to process other fragments of 

25 the same packet using the same methods as for the first fragment. 

The filter code described herein as interpreted may also be compiled into directly 
executable machine code by the policy manager, thus sending actual executable 
processor instructions to the IPSEC engine. 

Many optimizations on the executable programs are well known in the programming 
30 language and compiler literature, and have not been described here even though 
they apply to the filter code of this invention equally well as to other representations 
of programs. Methods for generating intermediate code from the set of rules are also 
well developed in the literature and known to those skilled in the art. 
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It is well-known to those skilled in the art that it is possible to structure the 
implementation quite differently from Fig. 3 without changing the essential content 
of this invention. For example, it is possible to implement the IPSEC engine and 
policy manager intermixed in the same module, or to implement the policy manager 
5 on above of key managers. 

Even though the invention was described in the context of the EPSEC protocol, it is 
also applicable to other cryptographic security protocols that encrypt data on the 
packet level. In that case all IPSEC-related definitions in the previously presented 
description must naturally be changed to the corresponding definitions in the other 
10 security protocol. 

Figs. 6a and 6b illustrate a data processing system 600 and a gateway device 650 
that can be used to reduce the invention into practice. The system 600 of Fig. 6a has 
an TCP/IP adapter 601 for connecting into a network 602. A microprocessor 603 
uses the TCP/IP adapter 601 to transmit and receive information over the network 

15 602. The microprocessor 603 has a core memory 604 for storing the operating 
system kernel during use, and a separate, usually larger storage 605 for running 
user-mode processes. The memory blocks 604 and 605 may be implemented as parts 
of a single memory circuit; alternatively at least a part of one and/or the other may 
be located on the same chip with the microprocessor 603. A nonvolatile mass 

20 memory 606 is also inlcuded for storing programs and data. Taken that the structure 
of Fig. 3 is employed, the packet interceptor and the IPSEC engine reside in the core 
memory 604 along with the rest of the operating system kernel, and the policy 
manager and key managers block of Fig. 3 use the storage 605 for their operation. 

The gateway device 650 is otherwise similar to the data processing system 600 but 
25 it contains two network adapters 651 and 652, one for connecting into an internal 
network 653 and one for connecting into a general data transfer network 654. The 
gateway device 650 is used to implement the IPSEC security features to protect the 
inhouse network 653 against attacks originating in the general data transfer network 
654. 

30 The devices of Figs. 6a and 6b are naturally shown as examples only and they do 
not limit the invention. The data processing system 600 and the gateway device 650 
may include other parts than those shown in Figs. 6a and 6b. 
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CLAIMS 

1. A data processing system for implementing a security protocol based on 
processing data in packets, characterized in that said data processing system 
comprises: 

- packet processing means (308) for storing filter code (304) and processing data 
packets (301) according to stored filter code, and 

. policy managing means (305) for generating filter code and communicating 
generated filter code to said packet processing means, 

wherein said packet processing means is arranged to examine (503, 504, 505), 
whether the stored filter code is applicable for processing a certain packet, and to- 
communicate (507) such packets for the processing of which the stored filter code is 
not applicable to said policy managing means, and said policy managing means is 
arranged to, as a response to receiving a packet from said packet processing means, 
either (508, 509) 

- generate filter code applicable for the processing of the packet and communicate 
the generated filter code to said packet processing means, or 

- process the packet by said policy managing means, or 

-process the packet by said policy managing means and generate filter code 
applicable for the processing of the packet and communicate the generated filter 
code to said packet processing means. 

2. A data processing system according to claim 1, characterized in that it further 
comprises a policy database (306) for storing a plurality of policy rules, wherein 
said policy database is implemented as a part of said policy managing means (305). 

3. A data processing system according to claim 2, characterized in that it further 
comprises key management means (307) for implementing the key management 
functions according to said security protocol, wherein said key management means 
is arranged to communicate with said policy managing means (305). 

4. A data processing system according to claim 3, characterized in that said key 
management means (307) and said policy managing means (305) are arranged to 
generate and maintain a plurality of security associations as specific applications of 
said policy rules and key management functions to certain communications. 
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5. A data processing system according to claim 4, characterized in that said policy 
managing means (305) is arranged to generate filter code on the basis of the 
information contained within said policy rules and said security associations. 

6. A data processing system according to claim 5, characterized in that said policy 
5 managing means (305) is arranged to communicate information about said security 

associations to said packet processing means (301) in addition to the generated filter 
code, and said packet processing means (301) is arranged to perform cryptographic 
transformations on packets, said cryptographic transformations being based on said 
filter code and said information about said security associations. 

10 7. A data processing system according to claim 6, characterized in that said policy 
managing means (305) is arranged to communicate information about only a 
fraction of the security associations known to said policy managing means (305) to 
said packet processing means (301). 

8. A data processing system according to claim 6, characterized in that said packet 
15 processing means (301) is arranged to store the filter code (304) separately from 

said information about said security associations. 

9. A data processing system according to claim 1, characterized in that it further 
comprises packet intercepting means (303) for separating data packets for the 
processing of which said security protocol is applicable from a general stream of 

20 packets, wherein said packet intercepting means (303) is arranged to communicate 
with said packet processing means (301). 

10. A data processing system according to claim 1, characterized in that it further 
comprises a kernel space (604) and a user-mode process space (605), wherein said 
packet processing means (301) resides in said kernel space (604) and said policy 

25 managing means (305) resides in said user-mode process space (605). 

11. A data processing system according to claim 1, characterized in that it further 
comprises a kernel space (604) and a user-mode process space (605), wherein said 
packet processing means (301) and said policy managing means (305) reside in said 
user-mode process space (605). 

30 12. A data processing system according to claim 1, characterized in that it further 
comprises at least two network interfaces (651, 652), wherein said packet 
processing means (301) is arranged to store separate filter code for each network 
interface. 
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13. A data processing system according to claim 1, characterized in that said 
packet processing means (301) is arranged to process mcorning and outgoing 
packets and store separate filter code for the processing of incoming and outgoing 
packets. 

14. A data processing system according to claim 1, characterized in that said filter 
code does not contain any backward jumps. 

15. A data processing system according to claim 1, characterized in that said filter 
code includes the operations of dropping a packet (504), passing a packet through 

(505) , and referring the packet to the policy managing means (507). 

16. A data processing system according to claim 15, characterized in that said filter 
code additionally includes the operation of applying a transformation to a packet 

(506) . 

17. A data processing system according to claim 1, characterized in that said 
packet processing means (301) is arranged to process packets in fragments, applying 
said filter code to the processing of the first fragment of a packet before receiving 
the other fragments and processing any remaining fragments of the packet 
separately using the actions deterrnined for the first fragment. 

18. A data processing system according to claim 17, characterized in that said filter 
code contains an instruction to require, as a response to receiving a fragment, a full 
packet before processing can continue. 

19. A data processing system according to claim 1, characterized in that said filter 
code consists of actual compiled processor instructions. 

20. A method for implementing a security protocol based on processing data in 
packets, characterized in that it comprises the steps of: 

a) examining (502, 504, 505), whether a piece of stored filter code is applicable for 
processing a certain packet in a packet processing means, whereby a positive result 
means that a a piece of stored filter code is applicable for processing a certain 
packet and a negative result means that a piece of stored filter code is not applicable 
for processing a certain packet, 

b) following a positive result in step a), processing (503, 506) the packet in said 
packet processing means according to the stored filter code, 
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c) following a negative result in step a), communicating (507) the packet into a 
policy managing means and examining (508), whether filter code should be 
generated and communicated to said packet processing means for the processing of 
the packet in said packet processing means, whereby a positive result means that 

5 filter code should be generated and communicated to said packet processing means 
and a negative result means that filter code should not be generated and 
communicated to said packet processing means, 

d) following a positive result in step c), generating (509) filter code applicable for 
the processing of the packet and communicating the generated filter code to said 

10 packet processing means, 

e) following a negative result in step c), exaniining, whether filter code should be 
generated and communicated to said packet processing means for the processing of 
further similar packets in said packet processing means, whereby a positive result 
means that filter code should be generated and communicated to said packet 

15 processing means and a negative result means that filter code should not be 
generated and communicated to said packet processing means, 

f) following a positive result in step e), processing the packet in the policy managing 
means and generating filter code applicable for the processing of further similar 
packet and communicating the generated filter code to said packet processing 

20 means, and 



g) following a negative result in step e), processing the packet in the policy 
managing means. 



WO 99/67930 



PCT/FI99/00536 



2/4 



309 



307 
305 

301 
303 



308 



KEY MANAGERS 



1 



POLICY MAN AGER 
A 



I 



IPSEC ENGINE 




PACKET INT ERCEPTOR 
* 



300 



302 



TCP/IP ADAPTER 
a? 



Fig. 3 



SELECTORS 

- SOURCE IP / MASK 
-DESTINATION IP /MASK 

- PROTOCOL 
-SOURCE PORT 

- DESTINATION PORT 



401 



TRANSFORMATION TO APPLY 



402 
403 
404 
405 
406 



KEY MATERIAL FOR TRANSFORMATION 



REPLAY PREVENTION DATA FOR THE TRANSFORMATION 



BYTES OF DATA TRANSMITTED 



EXPIRATION TIME AND DATA TRANSFER LIMIT 



Fig. 4 



WO 99/67930 



PCT/FI99/00536 



3/4 




Y 501^ 
READ PACKET 



Y 502- 



IP PACKET? 



YES Y. 

503^" 



APPLY FILTER CODE 
(PROCESS PACKET) 



V 504- 



YES, 



DROP PACKET? 




NO Y 505- 
ACCEPT PACKET? 



NO ^ 507-, 




508^ 


PASS TO 


> 


EXAMINE, DETERMINE 


POLICY MANAGEMENT 




POLICY RULES 


506>, 




y 


OUTPUT (PROCESSED) 
PACKET 




STORE 



Fig. 5 



WO 99/67930 



PCT/FI99/00536 



4/4 



.600 




Fig. 6a 




INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(19) World Intellectual Property Organization 
International Bureau 

(43) International Publication Date 
29 December 1999 (29.12.1999) 




PCT 



ttttt 



(10) International Publication Number 

WO 99/67930 A3 



(51) International Patent Classification 6 : H04L 29/06, 
12/22 

(21) International Application Number: PCT/FI99/00536 

(22) International Filing Date: 18 June 1999 (18.06.1999) 

(25) Filing Language: English 

(26) Publication Language: English 



(30) Priority Data: 
09/100,272 



19 June 1998(19.06.1998) US 



(71) Applicant (for all designated States except US): SSH 
COMMUNICATIONS SECURITY LTD. [FI/FI]; 
Tekniikantie 12, FIN-02150 Espoo (FI). 

(72) Inventors; and 

(75) Inventors/Applicants (for US only): N1KANDER, Pekka 
[FI/FI]; Suvannontie 12, FIN-00510 Helsinki (Fl). YLO- 
NEN, Tatu [FI/FI]; Taysikuu 10 C 88, FIN-022 10 Espoo 
(FI). 

(74) Agent: BERGGREN OY AB; P.O. Box 16, FIN-00101 
Helsinki (FI). 



(81) Designated States (national): AE, AL, AM, AT, AU, AZ, 
BA, BB, BG, BR, BY, CA, CH, CN, CU. CZ, DE, DK, EE, 
ES, FI, GB, GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, JP, 
KE, KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, MD. 
MG, MK, MN, MW, MX, NO, NZ, PL, PT, RO, RU, SD, 
SE, SG, SI, SK, SL. TJ, TM, TR, TT, UA, UG, US, UZ, 
VN, YU, ZA, ZW. 

(84) Designated States (regional): ARIPO patent (GH, GM, 
KE, LS, MW, SD, SL, SZ, UG,ZW), Eurasian patent (AM, 
AZ, BY, KG, KZ, MD, RU, TJ, TM), European patent (AT, 
BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT. LU, MC, 
NL, PT, SE), OAPI patent (BF, BJ, CF, CG. CI, CM, GA, 
GN, GW, ML, MR, NE, SN, TD, TG). 

Published: 

— with international search report 

(88) Date of publication of the international search report: 

4 October 2001 

For two-letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations" appearing at the begin- 
ning of each regular issue of the PCT Gazette. 



2 5 (54) Title: METHOD AND ARRANGEMENT FOR IMPLEMENTING IPSEC POLICY MANAGEMENT USING FILTER CODE 



309 



< 



307- 
305- 

301 
303- 









KEY MANAGERS 










POLICY MANAGER 









308 



ON 

o 



•306 



IPSEC ENGINE 



1 



PACKET INT ERCEPTOR 
x 



■304 



302 



TCP/IP ADAPTER 




/ 5 7) Abstract: A data processing system implements a security protocol based on processing data in packets. The data processing 
system comprises packet processing means (301 ) for storing filter code (304) and processing data packets according to stored filter 
code and policy managing means (305) for generating filter code and communicating generated filter code to the packet processing 
meaiis (301 ) The packet processing means (301 ) is arranged to examine, whether the stored filter code is applicable for processing 
a certain packet. If the stored filter code is not applicable for the processing of a packet, the packet is communicated to the policy 
managing means (305), which generates filter code applicable for the processing of the packet and communicates the generated filter 
code to the packet processing means (301). 



INTERNATIONAL SEARCH REPORT 



iroernaoonot Application no 

PCT/FI 99/00536 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 6 H04L29/06 H04L12/22 



According to international Patent Classification (IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (rtas&'&cauon system followed by classirtcation symbols) 

IPC 6 H04L 606F 



Documentatjon searched other man minimum oocumemailon to the extent nai sucn aocumsnts are inctuaad in the ft aids aovenee 



Election*; oase consulted during tho international search (name or oata base and, where practical, searcn terms usee) 



C DOCUMENTS CONSIDERED TO BE RELEVANT 



Category ' 



C'taton ot document, with Indication, where appropriate, of the reievam passages 



Relevant to claim NIc. 



WO 98 26555 A (MOTOROLA INC ;SUN 
MICROSYSTEMS INC (US)) 
18 June 1998 (1998-06-18) 
abstract 
page 3, line 
9, line 
11. 



1-20 



page 
page 
page 
page 
page 



11. 
14, 
17. 



10 -page 6, line 10 
23 -page 10, line 3 
line 5-9 

line 22 -page 12, line 8 
line 20 -page 15, line 14 
line 8-18 



m 



Funner documents are flsied in the continuation of box C. 



ID 



Patent family members am Rated In annex. 



* Spaciflj categories of cited aocumonts ; 

"A* document defining the general state of the art which is not 

considered to bo of particular rdovanee 
"E* earTter document but pub&sned on or after the UttemanonaJ 

(tang oate 

V document which may throw doubt* on priority etaim(s)or 

whicn 4* cried to establish the publication date ot onotner 
citation or other special reason (aa ipeojfted} 

V document referring to an orai disclosure, use, exhibition or 

other means 

*P* document puofishod prior to the InrcmcHoruiI flUno date but 
later man me priority data claimed 



T* laiardoajment published after the International ftmo 
or priority data and no; fn conflict witn the app0c3v> 
cited to understand the phndpto or theory undenytrxj j» 
Invention 

*X" docurnerrt of particular rdevanco: tho clalmec inv ention 
cannot be considered novel or cannot be considered to 
involve an inventive step when me cocumeni te taxen alone 

"V document of particular relevance: tne claimed ktvamtan 
cannot be considered to involve an tnvcrrhVe step when me 
decumeni Is comolncd with one or more otner such docu- 
ments, suen combination oetng oovtous to a person sullied 
In the art. 

"a" documem member of m« aame patent family 



Date ot the actual completion of tne international search 

15 October 1999 


Date ot mailing or me international searcn report 
25/10/1999 


Name and maiitno asoreaaofthe ISA 

European Patent Oraoa, pa. 5018 Patemiaan 2 
NL - 22ao rtv ftl£wl|K 
Tel. (+31-70) 340-2040. Tx, 31 651 cpO rf, 
Fax: (-31-70) 340-3016 


Authorized officer 

Lazaro Lopez, M.L. 



form PCTASA/210 (* 



j tn—i) (July 1092 j 



page 1 of 2 



INTERNATIONAL SEARCH REPORT 



tntet..«tlonal Application No 

PCT/FI 99/00536 



CfContlnuatton) DOCUMENTS CONSIDERED TO BE RELEVANT 



Caiego/y ° Chorion of document, with indicaiian.wnere appropriate, of the relevant passages 



Relevant to claim No. 



WO 97 00471 A (D0G0N GIL ; KRAMER SHL0M0 
(ID; SHWED GIL (IL); ZUK NIR (ID; BEN R) 
3 January 1997 (1997-01-03) 
abstract 

page 4, line 1-22 
page 5, line 5-30 
page 11, line 14-32 
page 22, line 23 -page 23, line 2 
page 30, line 5-17 
claims 1,6,9,18 

US 5 761 424 A (HOGLUND TIMOTHY E ET AL) 

2 June 1998 (1998-06-02) 

abstract 

column 1, line 65 -column 2, line 18 

column 2, line 53-67 

column 4, line 15-35 

column 4, line 66 -column 5, line 11 

column 5, line 38 -column 6, line 16 

column 6, line 46-67 



1-20 



1-20 



Form PCTVtSA/21 0 { cortmunlioci of sccono vtoct) (Jufy 1902) 

page 2 of 2 



INTERNATIONAL SEARCH REPORT 

Information on patent family mombors 



I nlw national Application No 

PCT/FI 99/00536 



Patent document 
cited tn ssarcti report 



Publication 
date 



Patent family 
member(s) 



Publication 
date 



WO 9S26555 



13-06-1998 



WO 9700471 



03-01-1997 



US 5761424 



02-06-1998 



1 1 c* 

US 


5848Z33 A 


08- 


-12- 


-1998 


us 


5606668 A 


25- 


-02- 


-1997 


AU 


6135696 A 


15- 


-01- 


■1997 


CA 


2197548 A 


03- 


-01- 


1997 


EP 


0807347 A 


19- 


-11- 


■1997 


JP 


10504168 T 


14- 


-04- 


1998 


NO 


970611 A 


15- 


-04- 


■1997 


US 


5835726 A 


10- 


-11- 


•1998 


CA 


2138058 A 


16- 


-06- 


•1995 


EP 


0658837 A 


21- 


-06- 


•1995 


JP 


8044642 A 


16- 


-02- 


•1996 


NONE 



Form PCT/iSA/210{pai»ni fwniry annex) (jjfy ifiSZ) 



